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(57) ABSTRACT 

A method of transmitting interleaved real-time and non-real- 
time data on a packet based network so as to provide voice 
Quality of Service comparable to the Time Division Multi- 
plexing realm of traditional telephony. The method reduces 
packet jitter and delay by employing separate queues for the 
different types of data as well as through the use of jitter 
buffers. The interleaving method consists of a number of 
discrete concepts and mechanisms that when used together 
in the manner disclosed herein provides consistent high- 
quality transmission of real-time data over packet/frame/ 
cell-based networks. The elements required for this method 
include time-slot co-ordination, a dynamic MTU algorithm, 
and a Multiple queue egress traffic management system. 

16 Claims, 4 Drawing Sheets 
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TDM-QUALITY VOICE OVER PACKET volume of data traffic will outstrip that of voice on public 

carrier networks. At that point, the existing Public Switched 

vm n op iNrvPMnniM Telephone Network (PSTN), whose technology is primarily 

rituj ur UNvtmiuiN based on circuit switching, will be used predominantly to 

This invention deals with the interleaving of data streams 5 carrv data for which a packet switching technology is a more 

of differing priorities in such a manner that real time data can appropriate alternative. Packet-switched networks can carry 

be delivered on a managed packet-based network in real voice calls using as little as 8 kilobits per second (Kbps) of 

time, while non-real time data is delivered in the bandwidth bandwidth to provide TDM quality voice compared to the 64 

remaining after the real time data has been transmitted. Kbps that is reserved for each call in the conventional PSTN. 

RArKPRnnism 10 ^ e P oten ^^ increase in capacity is attractive to telecom- 
munications service providers, as are the reduced infrastruc- 

Historically, entire separate communications systems ture costs associated with building packet-switched net- 
have been employed to transmit audio data, traditionally works. As a result, providers of new real time telephony 
referred to as "voice", and computer data, conveniendy services are increasingly using packet- switched network 
referred to as "data", although at present audio data and 15 architectures, a trend that will continue with the arrival of 
computer data both are considered to fall within the broad competition in the local phone market. The predominant 
definition of "data". Over a century ago analogue telephone packet -based network protocol in use today is the ubiquitous 
networks were developed to carry analogue audio signals. Internet Protocol (IP). The first attempts to use this technol- 
Telephone networks allow communication of audio signals ogy were implemented by hobbyists on the Internet. In these 
between two or more users by establishing, with central ^ early methods, an Internet telephony software program 
switching equipment, a temporary dedicated communication would convert the user's analogue voice signal to digital 
circuit or channel between the users. Because the channel, data, compress it, and transmit it as packets to an Internet 
once established, is dedicated exclusively to the transmis- server. For example, a full duplex real time telephone 
sionof signals between the users, the signals are not required conversation may be initiated over the Internet from one 
to compete for the channel's bandwidth with other unrelated ^ computer to another. Both computers generally require the 
signals. The advantage of having a dedicated channel for a same Internet telephony software, a microphone, a sound 
voice conversation is that any transmission delay from card, a minimum processor speed, a modem, specific 
speaker to listener is purely a function of the unfettered software, and a connection to an Internet Service Provider, 
speed of the audio signal through the telephone network. Both computers must be on-line simultaneously; which 
Since this speed does not significantly vary over time, such 30 requires either a pre-arrangement between callers or a sepa- 
dedicated channels are capable of providing isochronous rate telephone toll call. Software for that type of system is 
transmission. Unfortunately, one significant disadvantage of commercially available. 

dedicated channels is that they require significant band- Data packets traverse packet based networks by being 

width; that is, the complete bandwidth of the channel routed from 0Qe node t0 ^ next of mese hops takes 

remains available and dedicated to carrying the conversation 35 the packet closer to its destination. Each node along the 

even when no information is being transmitted, such as route ^ designated by a globally unique address. Each node 

during either conversational or inter-syllable pauses. To m me route looks at me destination address contained in the 

allow better utilisation of a given communication link, header of a packet and sends the packet in the direction of 

time-division multiplexing (TDM) systems, where voice i ts destination. At any time, a node along a particular route 

signals from a number of users are digitised and then the ^ can stop accepting, or block one or more packets. This may 

resulting bits are time compressed for transmission over the be due to any number of reasons: congestion, maintenance, 

same lmk. This scheme also provides isochronous transmis- node crashes, etc. Each routing node constantly monitors its 

sion while sharing the communication link. adjacent nodes and adjusts its routing table when problems 

In contrast, more recent packet transmission systems are occur. As a result, sequential packets often take different 

asynchronous, allowing the allocation of bandwidth on an 45 routes as they traverse the Internet. The audio quality of 

as-demanded basis. For instance, if a channel is highly duplex phone conversation over the Internet is often poor 

active, it may receive more than its pro-rata share of overall because of delays of transmission of packets, lost packets, 

bandwidth. When a channel's activities decline, its allocated and lost connections. The delays are unpredictable and are 

bandwidth likewise declines. Thus, packet transmission is usually caused by the dynamically changing conditions of 

adept at handling "burst/' transmission of data, wherein the 50 the network and the changing and often long routes through 

activity of each individual channel is subject to relatively which packets must pass to arrive at their destination. One 

wide variation. consequence of these delays and differing routes the packets 

All networks experience certain delays in end-to-end data follow, other than message lag, is that individual voice 

transmission therethrough, this delay (termed "latency") packets may arrive in a non-sequential order, 

affects the overall efficiency and effective bandwidth of the 55 Existing methods for reducing delay-related problems 

network. Packet-based computer networks, because they are include assorted error correction schemes, primarily repeat 

asynchronous, are further subjected to "jitter", defined as a codes, which transmit data packets multiple times, and 

change in the latency of the network as a function of time. parity codes, which use modulo arithmetic to achieve a fixed 

Jitter is largely unpredictable; however, the overall quantity value over a series of cells in a check accumulator. These 

of traffic on a network tends to increase both latency and 6 o techniques are well known in the art, as are their drawbacks, 

jitter. Jitter can only be corrected by ensuring constant The use of repeat codes is undesirable because of the 

latency, or by developing methods to compensate for its network resources wasted by sending multiple copies of a 

effects. The most common of these methods is the use of a single packet. Parity codes are hampered by implementation 

"jitter-buffer'' to store incoming data, thus hiding jittery problems that make both source encoding and destination 

transmissions from the listener. 65 decoding complicated. A simple "row-parity" scheme can be 

Given the ongoing rapid growth of data traffic compared employed easily by placing parity packets after a set number 

with the slow growth of voice traffic, it is foreseeable that the of packets, but is flawed because it can only be used to 
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correct an error if the receiver knows that all but one packet 
has been received correctly. More complex schemes, such as 
the one outlined in U.S. Pat. No. 5,883,891 use a "matrix- 
parity" concept which seeks to improve the audio quality of 
voice communication over the Internet by reconstituting 5 
delayed and/or missing packets based upon the packets that 
arrive in time. The system is "robust", in comparison to 
simpler row-parity schemes, because packets constituting 
the matrix are deliberately transmitted over multiple routes. 
If one route is subject to delays, or packet loss, the lost or Q 
delayed packets can be fully reconstituted in many cases. 
The system receiving the voiceband signal from a caller 
(host system) uses a software program, which arranges each 
set of incoming voice packets into a two or three dimen- 
sional matrix. For example, a matrix could consist of five 5 
rows and five columns for a total of twenty-five packets. A 
sixth row, composed of check packets and based upon the 
five packets in its column is added as is a sixth column 
whose elements are check packets based upon the rows of 
the matrix. The source node transmits the packets over an IP 
network, such as the Internet, to a destination node which 
performs the necessary parity check operations to determine 
the values of missing and/or delayed packets. If the decoding 
system is sufficiently fast, the effect, to the listener, is as if 
all the packets had arrived on time. The listener hears a ^ 
replica of the entire original voice. 

Though parity schemes such as these are more effective 
than repeat codes, they introduce additional complexity in 
both the encoding and decoding processes, and still cannot 
guarantee a quality of service equivalent to that of TDM 30 
telephony due to the inherently unpredictable nature of 
overly used, highly congested, public data networks such as 
the Internet. 

Packet-switching techniques typically involve variable 
and arbitrary delays, which are unacceptable for two-way 35 
communication involving real time signals. The human ear 
is critically sensitive to absolute delay greater than about 
200 ms. The ear is also critically sensitive to random delays 
or gap modulation, as well as to minute tones, inflections and 
pauses, particularly in human speech. Thus, a computer data 40 
network that must also transmit audio data is forced to cope 
with the communication of both bursty computer and time- 
sensitive audio data on the same backbone. 

These problems are compounded by call set-up difficulties 
that arise from an inability to pick an ideal transmission 45 
block size. This size is dependent upon numerous factors 
which include channel capacity, congestion, and data 
sources. Any packet that is larger than a maximum trans- 
mission unit (MTU) must be segmented, which introduces 
excessive overhead if the MTU is smaller than the majority 50 
of data packets from the source. If the MTU is too large on 
a congested channel, then excessive delays are introduced 
when non-real-time data is being transmitted and a real-time 
data packet is waiting for transmission. Thus the establish- 
ment of an MTU suitable for network transmission is 55 
important to systems that simultaneously contain real-time 
and non-real-time data packets. 

One method of determining the optimal MTU that is 
known in the art is to determine the maximum packet size 
that the path in the network between the two nodes can 60 
reliably transmit by interrogating the nodes that are passed 
in transit as to their capacity, and picking a packet size that 
is as large as the smallest capacity of any node in the route 
taken through the network. This method is overly restrictive 
as a result of the fact that the MTU is unable to change in 65 
response to dynamic bandwidth fluctuations. In addition to 
this drawback, the interrogation of a system with high 
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latency can adversely impact upon the time needed to 
establish a connection (i.e. an increase in the time required 
for handshaking). 

Because the MTU is the largest size a packet can be in a 
given network, it is common in the art to use the MTU as the 
segment size for the transport layer for transferring large 
files. This practice results in a large overhead cost at the host 
system where the large file is stored. Not only does each 
segment require substantial overhead when transmitted but 
each acknowledgement of the transmitted segments effec- 
tively doubles the overhead since the overhead per segment 
is constant regardless of the size of the data transfer. 

There has been a universal reluctance to increase the 
segment size above the network MTU and divide the seg- 
ments into two or more fragments. This reluctance stems 
from the fact that transmission protocols such as TCP/IP 
retransmit the entire segment if any fragment is lost or 
encounters an error, thus rendering the apparent savings at 
the host system of questionable value since the network 
communication processing costs rise as the segment size 
increases due to retransmission of entire segments when a 
single fragment is lost or is in error. 

An improved MTU determination scheme is outlined in 
U.S. Pat. No. 5,751,970. This patent outlines a process for 
determining and selecting an optimum segment size for 
transferring data across a network. In this method, the cost 
of transferring a segment equal in size to the MTU is 
sequentially compared to the cost of transferring segments 
which are integer incremented multiples of the MTU. When 
the comparison indicates that the cost of the incremented 
segments exceeds the cost of transferring the segment equal 
in size to the MTU, the sequential comparison is halted, and 
the segment size derived in the previous calculation is used 
for transferring the data. To do this calculation, an iterative 
procedure may be used or an approximate value can be 
calculated if certain characteristics of the network are 
known. Though using this non-iterative solution addresses 
the problem of increased handshake time that exists with 
both channel interrogation and an iterative approach, it does 
not accommodate changing network conditions. The 
changes in network conditions undermine the calculation of 
the MTU multiplier, causing the system to yield a sub- 
optimal segmentation size. 

One problem not addressed by methods common in the art 
is that the system parameters vary in real time in a non- 
deterministic manner. Prior art treats network communica- 
tions as either static or varying with time in a deterministic 
fashion. Network unpredictability is the result of stochastic 
processes that cannot be properly modelled. These unpre- 
dictable effects must be compensated for to achieve TDM 
Quality of Service (QoS) in a packet-based network. 

As a result of industry's desire to achieve TDM quality 
voice transmission the focus of attention has shifted from 
Internet telephony (carrying voice calls over the Internet) to 
IP telephony or Voice-over-IP (VoIP) using other IP 
networks, especially private network backbones. In its 
broadest sense, this is a move to packet based telephony, 
commonly called Voice over Packet (VoP), on private net- 
works which has been prompted, in large part, by the need 
to guarantee a minimum level of connectivity bandwidth, 
while reducing congestion problems. The second benefit of 
this private network approach is that it affords a greater 
ability to predict network conditions, and to identify points 
of probable congestion. 

Additionally, with a private network, it is possible to 
prioritise packets derived from real-time sources such as 
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voice transmissions (henceforth referred to as voice packets) 
over packets derived from computer based information 
sources (henceforth referred to as data packets) utilising a 
queuing scheme. The Internet generally is unreliable for 
high quality voice telephony because the TCP/IP protocols 5 
currently do not provide for reserving bandwidth to guar- 
antee QoS. Thus, the quality of VoIP calls is adversely 
affected by unpredictable network congestion that can cause 
packet delays or losses. For these reasons environments such 
as the public Internet or another public packet network, 
which are marked by dramatic and uncontrollable fluctua- 
tions in load, cannot guarantee an acceptable voice connec- 
tion. Private networks, using either IP or another packet 
oriented protocol, can provide high quality voice services 
because their traffic can be managed to a higher degree. 

This ability to assign higher priority to a particular type of 15 
packet is termed Grade of Service (GoS) in the art. Though 
present implementations are an improvement over standard, 
unprioritised IP, they are not as effective as the TDM- 
world's QoS guarantee, because GoS is only a relative 
guarantee. In effect GoS says that it will transmit one type 20 
of packet ahead of another, but is Limited in both the number 
of grades available and in its ability to guarantee that a 
packet, of any grade, will be reliably received. In compari- 
son QoS is an absolute and quantifiable guarantee, which is 
able to deliver higher priority packets over lower priority 25 
ones. This obstacle, along with several others, is overcome 
by the present invention. 

SUMMARY OF THE INVENTION 

It is an object of this invention to provide a solution to the 3Q 
above mentioned obstacles by providing a method of com- 
municating Voice over IP (VoIP) gateways that provides 
voice Quality of Service (QoS) comparable to the Time 
Division Multiplexing (TDM) realm of traditional tele- 
phony. The method is primarily concerned with reducing 35 
packet jitter and delay at the launching gateway. 

It is another object of this invention to have the jitter and 
delay introduced at the launching end compensated for at the 
receiving gateway by mechanisms such as a jitter buffer, 

It is yet another object of the invention to have the 40 
launching gateway reduce impairments due to limitations in 
the jitter buffer size to negligible amounts. The reduction of 
jitter provided for herein aids in allowing TDM-Quality 
service using packet based transmission networks. 

It is yet another object of this invention to provide a 45 
method of interleaving other types of real-time data, such as 
facsimile or video, with non-real-time data over a stream of 
mixed data units, such as packets, that combine both types 
of data while giving a higher priority to the real-time data. 

The interleaving method disclosed herein consists of a 50 
number of discrete concepts and mechanisms that when used 
together in the following manner provides consistent high- 
quality transmission of real-time data over IP or other 
packet/frame/cell-based networks. The elements required 
for this method include: 55 

1. Time-slot co-ordination 

2. Dynamic MTU algorithm 

3. Multiple queue egress traffic management system (e.g., 
high/low priority queues or real-time/non-real-time 
queues) that is synchronised with the co-ordination of 60 
time slots. 

Time-slot co-ordination is a concept that is novel in 
packet based networks, though it is well used in the TDM 
environment. 

TDM-Quality Voice over Packet is particularly intended 65 
for those situations where QoS must be provided to support 
real-time applications such as voice or video. 
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It is an object of the present invention to provide a 
communication system for interleaving non-real-time data 
(NRD) and real-time data (RTD), said RTD representing at 
least one of n analogue signals, each signal received from at 
least, one of n calls, for transmission over a data network, 
having a predetermined network bandwidth, said system 
comprising four elements. The first element is a non-real- 
time queue for receiving the NRD. The second element is a 
real-time queue for receiving the RTD. The third element is 
a network interface responsive to the non-real-time queue 
and the real-time queue for combining a maximum trans- 
mission unit (MTU) that contains a segment of the NRD, 
with a real-time window (RTW) that contains a segment of 
the RTD, into a launch window having a predetermined 
launch interval. The fourth element is an MTU calculation 
unit for determining a permissible size in bits for the MTU 
equal to at most the launch window size minus a size for the 
RTW suitable to permit a synchronised transmission of said 
RTD within the launch interval based on the network 
bandwidth. One aspect of the current invention is to provide 
a communication system, as described above further com- 
prising fragmentation means responsive to the MTU calcu- 
lation unit for fragmenting the NRD into a plurality of data 
fragments, each fragment having a size suitable for fitting 
within one of a corresponding plurality of MTUs. Another 
aspect of the current object of the invention is to provide a 
communication system as described above, wherein the 
launch window has a size in bits equal to the product of the 
launch interval in seconds and the network bandwidth in bits 
per second. A further aspect of the current invention is a 
communication system as described above, wherein the 
RTW has a size in bits equal to a predetermined number of 
protocol overhead bits plus a product of n, a pre-selected call 
density coefficient and a pre-selected block size in bits. Yet 
another aspect of the current invention is a communication 
system as described above, wherein each one of the n calls 
has a respective call density coefficient (CDC) and a respec- 
tive block size, and wherein the RTW has a size in bits equal 
to a predetermined number of protocol overhead bits plus a 
sum of n products corresponding to the n call, each product 
obtained by multiplying the respective CDC and the respec- 
tive block size in bits of each one of the n calls. Another 
aspect of the current invention is a communication system as 
described above, wherein the at least one of the n calls 
carries a voice signal. Another aspect of the current inven- 
tion is a communication system as described above, wherein 
the at least one of the n calls carries a facsimile signal. 
Another aspect of the current invention is a communication 
system as described above, wherein the at least one of the n 
calls carries a video signal. 

Another object of the current invention is a method of 
interleaving non-real-time data (NRD) with real-time data 
(RTD) representing analog signals from at least one of n 
calls, into a combined data stream, to be transmitted over a 
data network having a predetermined bandwidth, said 
method comprising the following three steps. The first step 
is the receiving and queuing the NRD. The second step is the 
receiving and queuing the RTD. The third step is the filling 
of a segment of the RTD into a real-time window (RTW) to 
form a first part of a launch window having a pre-selected 
size and a predetermined launch interval, wherein the RTW 
has a size suitable to permit a synchronised transmission of 
the RTD within the launch interval based on the network 
bandwidth. The fourth step is the filling of a segment of the 
NRD into a maximum transmission unit (MTU) to form a 
second part of the launch window, wherein the MTU has a 
size equal to at most the launch window size minus the RTW 



09/15/2004, EAST Version: 1.4.1 



US 6,5' 

7 

size. One aspect of this object of the invention is an 
interleaving method as described above, further comprising 
the step of fragmenting the NRD into a plurality of data 
fragments, each fragment having a size suitable for fitting 
within one of a corresponding plurality of MTUs. Another 
aspect of the current invention is an interleaving method as 
described above, wherein the launch window has a size in 
bits equal to the product of the launch interval in seconds 
and the network bandwidth in bits per second. Yet another 
aspect of the current invention is an interleaving method as 
described above, wherein the RTW has a size in bits equal 
to a predetermined number of protocol overhead bits plus a 
product of n, a pre-selected call density coefficient and a 
pre-selected block size in bits. Yet a further aspect of the 
current invention is an interleaving method as described 
above, wherein each one of the n calls has a respective call 
density coefficient (CDC) and a respective block size, and 
wherein the RTW has a size in bits equal to a predetermined 
number of protocol overhead bits plus a sum of n products 
corresponding to the n call, each product obtained by 
multiplying the respective CDC and the respective block 
size in bits of each one of the n calls. Another aspect of the 
current invention is an interleaving method as described 
above, wherein the at least one of the n calls carries a voice 
signal. Another aspect of the current invention is an inter- 
leaving method as described above, wherein the at least one 
of the n calls carries a facsimile signal. Another aspect of 
the-current invention is an interleaving method as described 
above, wherein the at least one of the n calls carries a video 
signal. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Exemplary embodiments of the invention will now be 
further described with references to the drawings in which 
same reference numerals designate similar parts throughout 
the figures thereof, and wherein: 

FIG. 1 illustrates an exemplary network configuration that 
accommodates a TDM Quality Voice over Packet system in 
accordance with this invention; 

FIG. 2 illustrates in a schematic block diagram a Voice 
over IP Gateway that accommodates a TDM Quality Voice 
over Packet system in accordance with this invention; 

FIG. 3 illustrates the process of filling a mixed data unit 
with real-time and non-real-time data in accordance with 
this invention; and 

FIG. 4 shows the serialization time (milliseconds) for 
packets of various sizes onto access network links of various 
speeds. 

DETAILED DESCRIPTION OF THE 
INVENTION 

FIG. 1 illustrates one of several possible network con- 
figurations to which embodiments of this invention are 
applicable. A conventional Public switched telephone net- 
work 1 shown as a cloud is the interface to a circuit-switched 
voice network. A public data network 2 is any one of a 
private enterprise network, an Internet Service Provider 
(ISP) network, or another Public Data Network (PDN). Both 
the telephone network 1 and the IP data network 2 connect 
to a service provider's Voice over IP (VOIP) Gateway 3, 
which is provided by a service provider such as a local 
exchange carrier (ILEC) or a competitive local exchange 
carrier (CLBC). The AfolP Gateway 3 is responsible for 
converting telephony and other voice-band signals and sig- 
nalling information into IP packets, which are interleaved 
with user non-real-time IP traffic and sent to other VoIP 
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gateways 5 over an access network 4, which is an estab- 
lished packet based network. Examples of such a packet- 
based network include those using Internet protocol (IP) or 
another packet-based protocol such as Frame Relay or ATM. 

5 The \bIP gateway 3 in turn uses its TDM Quality Voice 
over Packet process (TQVoP) to interleave the information 
from both the telephone network 1 and the data network 2 
for transmission over the access network 4. The access 
network 4 is a managed network whose throughput and 

10 latency characteristics are known. This access network 4 
typically incorporates Layer 2 technologies, has sufficient 
bandwidth, and is planned and managed by the respective 
service provider. Examples of delivery channels used within 
the access 4 include digital subscriber lines (xDSL), that are 

15 either asymmetrical (ADSL) or symmetrical DSL (SDSL), 
cable modems, and dedicated Tl or DS1 lines. 

The access network 4 terminates in other VoIP gateways 
5 at the client site. The TQVoP process of the client site's 
VoIP gateway 5 allows the connection of the access network 

20 4 to both the private IP network 6 including a group of LAN 
based IP devices 7 of the service subscriber, and to a private 
telephone network 8, such as a 

Private Branch Exchange (PBX). The service subscriber 
is likely to use telephone sets 9 and/or PBXs (not shown) for 

25 voice access. Telephone devices 9 and other voice-band 
devices (e.g., modems, FAX, etc.) connect to the VoIP 
gateway via an analogue telephony interface. 

FIG. 2 illustrates a Voice over IP Gateway that accom- 
modates a TDM Quality Voice over Packet (TQVoP) system 

30 10 in accordance with this invention. This TQVoP system 10 
can be implemented with any packet based communications 
protocol. However, in the following we shall describe an 
embodiment of the TQVoP 10 to be implemented with the 
ubiquitous Internet protocol network. Here, the system per- 

35 forms the following processes: 

1. A time-slot co-ordination process 11 synchronises the 
creation of voice packets to be fitted within a mixed data 
unit that is launched in a launch interval of a pre-selected 
duration, such that voice packets are created and are ready 

40 to transmit immediately before the next-scheduled launch. 

2. A dynamic IP MTU process 12 calculates an optimum 
maximum transmission unit (MTU) value for the non- 
real-time data (NRD) portion of the mixed data unit that 
is provided to an IP forwarding or routing subsystem. 

45 3. An egress traffic management process (not shown) inter- 
leaves voice-band (real-time) data packets and LAN- 
based (non-real-time) data packets. This process includes 
a priority queuing mechanism on the egress interface to 
prioritise real-time over non-real-time data. At least two 

50 egress queues are required. In this exemplary 
embodiment, two queues are used; A high priority queue 
13 is reserved exclusively for real-time data packets. An 
interface handler 21 always empties this queue first. A 
second normal priority queue 14 is used by all other 

55 non-real-time data types (e.g., LAN-originated, OAM&P, 
signalling, etc) and is only serviced if the high priority 
queue 13 is empty. 

For the purposes of this description a time slot is defined 
in units of time, rather than in terms of a data block length. 

60 The start of every time slot is used for the real time data that 
is waiting, and then, if any space is left in the time slot, 
non-real time data is taken until the next time slot starts. In 
this process, real-time (voice) packets are created by pack- 
etising the digital samples received from an analog-to-digital 

65 converter, in this case a CODEC 31, in time to be sent at the 
start of the next launch window before the delay reaches an 
unacceptable length. Thus, a mixed data unit combining 
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real-time and non-real-time data is transmitted within the tocol (UDP), TP-4, etc.), and the Session Layer 5 (e.g., 

launch window during a pre-selected launch interval. The Real Time Protocol (RTP), Real Time Control Protocol 

launch window contains a real-time window and the MTU. (RTCP), etc.). 

Hie Dynamic MTU process 12 is defined in terms of an g) The number of set-up calls n is a whole integer value 

algorithm expressed through the mathematical formulae 5 supplied by the Voice Processing Subsystem that cor- 

used to calculate the MTU value, as follow. responds to the number of active voice-band calls. The 

Voice Processing Subsystem is required to notify the 

MTU = Launch Window- Real Time Window (1) T Q VoP s y stem u P on aD Y <*11 Set-up or teardown. 

^ Wh > h) The Call Density Coefficient (CDC) is a measure of the 

10 probability that a particular voice-band call will be 
wbere actively transmitting. In other terms, it is the probabil- 

ity that the particular call CODEC will have a real-time 
packet ready to transmit. As an example, a CDC of 0.5 

Launch Window = Launch Interval x End- to- End Bandwidth < 2 > means that this Call will be silent 50% of the time, 

tKCCedl) implying that this call has a 50% chance of having to 

send data at any given launch time. The following 
Real Tinw Windows Fixed Protocol Overhead + 0) ample CDC's are given just as examples, which can be 

n used in a preferred embodiment: speech transmission 

^(Call Density Co- efficient ^Voice Block S'w) 0.5; MODEM transmission 1.0; Dial Tone 1.0; Dual 

Tone Multi-Frequency (DTMF) transmission 1.0; Fac- 
simile Inband transmission 1.0; Facsimile Relay Trans- 
The individual components in the above algorithm are missio11 08 ******* CDC values must be based on 

defined as follows: actual usage patterns and other historical data, wher- 

a) The Maximum Transmission Unit (MTU) defines the TiTScfc ^ferahly provided by the Voice Processing 
largest size of a packet that can be earned by an 25 for ^ ^ ^ ^ ^ f J> 
interface protocol in , the ^communications protoco . If a ^ si d T Alternatively a Provisioning 
packet to be transmitted is larger than the MTU listed $ b ^ d Qn engineering/admillis U ve policy is ^ 
ui the IP Forward Table at a given network node, the for ^ ^ ^ CDC ^ ^ ^ 
packet is fragmented, by an IP fragmentation process between 0 and 10 

i 1 ' iD ^ ™ ^ S^f ^ * ' 30 The MTU algorithm described above allows per-call 

than the MTU. The MTU value u> determined by ement b affording each channel ^.Unot 

subtracttng the portion of launch window consumed for characteristi where each real time ttansmission ^ gi ven a 

the real-toe window, from the total available launch CDC ^ ^ a rf method bm ft does ^ dd ^ 

window. The result is then rounded up to a multiple of ^ computational ^^ty of the algorithm. In a simpler 

me basic packet aze and given to a Forward Table. For 35 Sterna* embodiment W» ^ ^ ^ oritbm J the 

purposes of an IP network, the MTU is rounded up to • XjrrTT . . A r . u r. 

v r in* i f aa dynamic MTU algorithm, an in depth per-call management 

tne nearest multiple ot 64. system fa used Iq sucn aQ embodiment, one CDC 

b) The Launch Interval is an arbitrary time interval chosen ^ applied to all calls evenly. This way, the per-call man- 
to loosely correspond to CODEC sample collection agement of activity is eliminated by making assumptions on 
times. For purposes of this exemplary embodiment, the w an entire group of active calls. To do this equation (3) is 
synchronised launch interval is assumed to be 10 ms. replaced by a simpler equation (3J: 

c) The launch window is the interval between voice 

launch slots (in bits). To define the launch window in Fixed , Number call (3s) 

units of bits, the launch interval is multiplied by the Ae Real-Time , I , J"™ 

, j ^ , A JL J . 45 . = irowcoi +. of Setup x Density x Block 

bandwidth (m bits/sec). The end-to-end bandwidth is Window n „„4, M(1 

used for the calculation. ™ 1 CedB ^ Size ■ 

d) End-to-end bandwidth is the link speed (in bits/second) 

of the slowest connection between two nodes in the In the simpler dgoriihm, a typical CDC value of 0.6 is 

path between the originating and destination nodes. 50 pre f erred for most tvpes of traffic, implies a 60% 

This is determined by the customer access link or probabi i ity mal a voice-band call will have data waiting to 

virtual circuit (VQ within the access network. Its value launch when xvrUxd by me egress Dandwidth manage ment 

is preferably derived from the speed of the egress ^ ^ ^ is changeable through provisioning, and 

interface serial link. Alternatively, a provisionable shcmld preferablv be derived ^ use of statistics 

value is used. 55 arising from network traffic studies. 

e) The real-time window is the sum of the fixed protocol ] n a hardware embodiment of the present invention, the 
overhead of the voiceband data-containing packets and VoIP gateways 3 and 5 shown in FIG. 1 have their hardware 
the probable traffic expected from each of the active designed for performing the process described above. FIG. 
voice-band calls. 2 illustrates the function of the VoIP gateway in the form of 

f) The fixed protocol overhead is the total number of bits 60 a block diagram. A Voice Processing System (VPS) 30, 
consumed by protocols operating at the Data link containing a CODEC 31, a Signal Type Classifier (STC) 32 
Layer 2 (e.g. Asynchronous Transfer Mode (ATM), and a packetiser 33, is employed to interpret a voice-band 
Point-to-Point Protocol (PPP), Frame Relay, Ethernet, signal VS, which is from a Telephony Interface 40. The 
etc.), the Network Layer 3 (e.g., IP, Internetwork voice signal VS is used as an input to both the STC 32 and 
Packet Exchange (IPX), Connectionless Network Ser- 65 the CODEC 31, The STC 32 analyses the incoming voice 
vice (CLNS), etc), the Transport Layer 4 (e.g. Trans- signal VS and determines the number of calls contained, and 
mission Control Protocol (TCP), User Datagram Pro- the CDC of each call. This call information is sent to the 
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TQVoP block 10 as signal d. The voice signal VS is into the largest possible window, it is fragmented before 

digitised by the CODEC 31 and sent to the packetiser 33, transmission. The dynamic MTU algorithm 12 determines 

where a streaming binary signal representing the real-time the size of the fragments. 

data of VS is packetised. The packetised real-time data, and FIG. 4 provides the serialisation time (in milliseconds) for 

the call information CI derived in the STC 32 are both sent 5 packets of various sizes onto access network links of various 

to the TQVoP Process 10. speeds. 

Hie IP Data Interface 42 provides non-real-time IP pack- FIG. 3 illustrates the example of a network with a 

ets to the IP Forwarding Lookup Unit 43, where the desti- bandwidth of 1 Mbit/s carrying ten active calls, each of 

nation of IP packets is planned as an orderly grouping of which has a CDC of 1.0 (each call is utilising the full 

hops through the network. The IP Forwarding Lookup 10 spectrum allocated to it). Each real time packet 50 contains 

places the routing information needed into the header of the the sampled data of 5 calls over a 20 ms timeframe, and one 

IP packets and forwards them to the IP Fragmentation Unit such packet is transmitted at the start of every 10 ms launch 

41. The IP Fragmentation Unit 41 uses the MTU calculated window. Assuming a sixteeo-bit sample per call each real- 

in the TQVoP 10 process* MTU Calculator 12 to fragment time packet consumes 212 bytes and requires approximately 

the IP packets as needed before sending them to the TQVoP 15 a 1.7 ms real time window 51 of the 10 ms launch window 

10. A Provisioning System 44 is optionally used to specify 52. This allows at most 8.3 ms of the launch window for the 

available bandwidth on the access network and relays a non-real time data 54 to use. This 8.3 ms window is the 

signal B to the TQVoP process 10 to facilitate this. The non-real-time window 53. This is the manner which the 

TQVoP Process 10, comprising a Time-slot Co-ordination system uses to transmit real time data 50 in the first portion 

unit 11, a Dynamic MTU Calculation unit 12, and both real 20 of the launch window 51 and allows the use of the remaining 

time 13 and non-real time 14 queues, receives information launch window 53 available for other types of data packets 

from several different sources, and outputs information to 54. 

several units. Signals CI, B and B 1 (a bandwidth measure Note that in this example, the available launch window on 
provided by the Packet Network Interface 21) are used as the link for non-real time traffic 54 is at most 8.3 ms or 1037 
input to the Dynamic MTU Calculation (DMC) Unit 12. The 25 bytes (depending on the domain: seconds or bits) wide. In 
DMC unit 12 provides a signal, MTU, to the IP Fragmen- order to avoid introducing packet jitter and delay at the 
tation Unit 41, that is used to determine the maximum size access network link, the non-real time traffic 54 must not 
that an IP packet can be for transmission, if the packet is interfere with the regularly scheduled transmission of real 
larger than the determined maximum, it is fragmented into time traffic 50. To achieve this it will be necessary to 
pieces no larger man me MTU. The Time-slot Co-ordination 30 fragment non-real time packets 54 that are too large to fit 
Unit 11 allows the synchronisation of the CODEC 31 and the into the time remaining in the launch window on the link, or 
packetiser 33 with the Real Time Queue 13, so that packets it may be necessary to suppress the transmission of a 
are prepared for launch near the start of the launch window non-real time packet 54 until the next window 55 is avail- 
time frame, so that there is negligible delay introduced to able. 

their transmission. The Real-Time Queue 13 accepts the 35 The Dynamic IP MTU algorithm determines the probable 

signal VP from the VPS's packetiser 33, which contains the window size based on the number of active voiceband calls 

real-time packets that comprise the digitised version of and densities. This transmission window (expressed in either 

signal VS. The Non-Real-Time Queue 14 accepts input from milliseconds or bytes) is translated into the 'largest frame 

the IP Fragmentation unit 41 (signal IPPF), which contains size* (expressed in bytes) and inserted into the IP Forward 

either IP packets or fragments of IP packets. The TQVoP 40 Table 43 under the MTU column. The IP Fragmenter 43 will 

process 10 unloads the Real-Time Queue 13 at the start of fragment outgoing IP packets into just the right size to fill the 

the launch window, and only turns to the Non-Real-Ume available window without affecting voice launch times. 

Queue 14 when the Real-Time Queue 13 is emptied. These Due to the dynamic nature of the real time data, it is 

two queues deliver their contents to the pace Network possible that there may be situations where the MTU listed 

Interface 21 (PNI), which facilitates the transmission of the 45 in the Forward Table 43 is not current. The number of setup 

interleaved data stream to the packet network. calls or the CDC may have changed but not enough to 

The following specific example is presented for the pur- trigger a MTU recalculation. In cases such as this, the 

pose of explanation, and should be considered to be neither real-time launch window 51 is able to slide to accommodate 

limiting in the scope of the invention, nor should it be packets that are larger than the current launch window size; 

considered the only embodiment envisioned. For ease of 50 The algorithm will quickly catch up to the new situation, 

understanding references are made to elements of both FIG. In the previous example a data stream composed of a mix 

1 and FIG. 2. of real time packets 50 and non-real time packets 54 is 

The VoIP gateways 3 transmit packets containing real delivered to a destination gateway 5. At that gateway 5 the 

time traffic at regular, well-defined launch intervals. Due to destination IP address of the packet is examined. If the 

the real-time nature of this traffic an egress traffic manage- 55 address of a packet does not match the receiving gateway, 

ment system (not depicted) is used to ensure that real time the packet is sent towards its destination (7 or 8). If the 

packets are given the highest priority on the access network packet does match the gateway routes it to the port desig- 

4. The intervals between the high priority bursts of real time nated by the addressing information. This decouples voice 

packets define the remaining time window available to other packets from the data stream. The voice packets are then 

types of data packet traffic. eo decoded into an audio signal by a CODEC (not shown). 

Depending upon the speed (expressed in Kbits/sec) of the What is claimed is: 

access network link 4, the remaining time window defines 1. A communication system for interleaving non-real-time 

the maximum size that other data packets can be transmitted data (NRD) and real-time data (RTD), said RTD represent- 

at without introducing either jitter or delays to the real time ing at least one of n analogue signals, each signal received 

packets. Packets that are too large to fit into the time 65 from at least one of n calls, wherein n is an integer greater 

remaining in the available window are either delayed until than 1, for transmission over a data network, having a 

the next available window, or if the packet is too large to fit predetermined network bandwith, said system comprising: 
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(a) a non-real-time queue for receiving the NRD; 

(b) a real-time queue for receiving the RTO; 

(c) a network interface responsive to the non-real-time 
queue and the real-time queue for combining a maxi- 
mum transmission unit (MTU) that contains a segment 5 
of the NRD, with a real-time window (RTW) that 
contains a segment of the RTD, into a launch window 
having a predetermined launch interval; and 

(d) MTU calculation means for determining a permissible 1Q 
size in bits for the MTU equal to at most the launch 
window size minus a size for the RTW suitable to 
permit a synchronized transmission of said RTD within 
the launch interval based on the network bandwidth. 

2. A communication system as in claim 1, further com- J5 
prising fragmentation means responsive to the MTU calcu- 
lation means for fragmenting the NRD into a plurality of 
data fragments, each fragment having a size suitable for 
fitting within one of a corresponding plurality of MTUs. 

3. A communication system as in claim 1, wherein the ^ 
launch window has a size in bits equal to the product of the 
launch interval in seconds and the network bandwidth in bits 
per second. 

4. A communication system as in claim 1, wherein the 
RTW has a size in bits equal to a predetermined number of ^ 
protocol overhead bits plus a product of n, a pre-selected call 
density coefficient and a pre-selected block size in bits. 

5. A communication system as in claim 1, wherein each 
one of the n calls has a respective call density coefficient 
(CDC) and a respective block size, and wherein the RTW 3Q 
has a size in bits equal to a predetermined number of 
protocol overhead bits plus a sum of n products correspond- 
ing to the n call, each product obtained by multiplying the 
respective CDC and the respective block size in bits of each 
one of the n calls. 35 

6. A communication system as in claim 1, wherein the at 
least one of the n calls carries a voice signal. 

7. A communication system as in claim 1, wherein the at 
least one of the n calls carries a facsimile signal. 

8. A communication system as in claim 1, wherein the at ^ 
least one of the n calls carries a video signal. 

9. A method of interleaving non-real-time data (NRD) 
with real-time data (RTD) representing analog signals from 
at least one of n calls, wherein n is an integer greater than 
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1, into a combined data stream, to be transmitted over a data 
network having a predetermined bandwidth, said method 
comprising the steps of: 

(a) receiving and queuing the NRD; 

(b) receiving and queuing the RTD; 

(c) filling a segment of the RTD into a real-time window 
(RTW) to form a first part of a launch window having 
a pre-selected size and a predetermined launch interval, 
wherein the RTW has a size suitable to permit a 
synchronized transmission of the RTD t within the 
launch interval based on the network bandwidth; and 

(d) filling a segment of the NRD into a maximum trans- 
mission unit (MTU) to form a second part of the launch 
window, wherein the MTU has a size equal to at most 
the launch window size minus the RTW size. 

10. An interleaving method as in claim 9, further com- 
prising the step of fragmenting the NRD into a plurality of 
data fragments, each fragment having a size suitable for 
fitting within one of a corresponding plurality of MTUs. 

11. An interleaving method as in claim 9, wherein the 
launch window has a size in bits equal to the product of the 
launch interval in seconds and the network bandwidth in bits 
per second. 

12. An interleaving method as in claim 9, wherein the 
RTW has a size in bits equal to a predetermined number of 
protocol overhead bits phis a product of n, a pre-selected call 
density coefficient and a pre-selected block size in bits. 

13. An interleaving method as in claim 9, wherein each 
one of the n calls has a respective call density coefficient 
(CDC) and a respective block size, and wherein the RTW 
has a size in bits equal to a predetermined number of 
protocol overhead bits plus a sum of n products correspond- 
ing to the n call, each product obtained by multiplying the 
respective CDC and the respective block size in bits of each 
one of the n calls. 

14. An interleaving method as in claim 9, wherein the at 
least one of the n calls carries a voice signal. 

15. An interleaving method as in claim 9, wherein the at 
least one of the n calls carries a facsimile signal. 

16. An interleaving method as in claim 9, wherein the at 
least one of the n calls carries a video signal. 

***** 
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